This document relates to Session Management of Internet Protocol (IP) communication sessions. Enterprises are increasingly using portals for collaborative internet processes. For example, Application Service Providers (ASPs) applications and content through a portal to a client using a standard internet browser. One goal is to no longer have dedicated client software installed on each client computer of an enterprise or group or related users.
In such a scenario, a client browser is used to access an application, i.e. the client browser sends one or more requests to a server invoking that application and performing certain steps within the application. The application needs certain resources (memory, connections, data locks, etc.) that it must acquire to service the requests of the user. Some or all of these resources must be held by the server while the server/application is waiting for subsequent requests from the user. This is known as “server state,” or more specifically, a “session” or “user session” (i.e. holding the data for the particular user).
The standard internet protocol for communication between a client browser and a server or portal is the hypertext transport protocol (HTTP). HTTP is stateless/connectionless, meaning there is usually no “leaving” the application, and the user can actually just close the browser without the server noticing. The concepts herein are described primarily in the context of using a portal, where a user navigates to portal pages to access applications that are generally started via URL in an IFRAME. In this context, “leaving the application” simply means leaving the portal page that contains or which started that application. Note however that the concept is not necessarily limited to the portal case.
When an application is accessed from a server, the server must keep the resources it holds ready for the particular user session, not knowing if the user will “return,” and instead only wait for a timeout. Acquiring such resources on the server, or even a write lock as is typical for complex change operations, is very costly and can lead to unacceptable results. Thus a mechanism is needed to notify the server when the user leaves the application, or even when the user just closes the browser.
One such mechanism includes the server sending a special Session Termination URL (STU) embedded in a response when the server holds state and/or resources that must be freed when the user “leaves” content or an application provided by the server. The STU is a termination URL that the server provides to terminate the particular session of the particular user. When the user leaves the portal page, the STU is sent to the server so that the server can immediately terminate the user session and release all resources held for that application for that user. This STU is picked up by a Session Termination Agent (STA), a script waiting in the browser and part of the portal, and then remembered within the STA. The STA is located in a frame outside of the frame that contains the application.
Two occurrences are crucial to effective session management according to the mechanism described above: first, the server sending the STU as part of the response and the STA waiting in the browser that will pick up the STU and remember it; and second, the client recognizing that the current page has been left, which triggers sending the STU. In the mechanism described above, the second step above can be performed by detecting a “page unload” event raised by the browser. This has the advantage that three kinds of “page left” cases associated with a portal can be captured with one technology: (1) The user moves to another portal page (by portal navigation), (2) the user selects a browser favorite and displaces the portal (including the application), and (3) the user simply closes the browser.
One disadvantage is that for each portal page request (i.e. a request to go to a new page), there is also a second request from the STA in the browser if the last page contained an application that needs a session termination. This means that for heavy use of server session termination, for each portal page request there are two requests coming from the browser. The first is a request to a content server to terminate the session (STA sends the STU it has stored), and the second is a request to the portal server for the “next page.” Since the browser has a limitation of bandwidth and a number of connections it can use, the termination request effectively delays the content of that “next page.”